T8099: strongswan: 6.0.6 + Post quantum options#5267
Conversation
* Update required strongswan version to 6.0.6 * Add options for mlkem*
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds post-quantum ML-KEM Diffie-Hellman groups (dh-group33, dh-group34, dh-group35) to IPsec configuration. Updates strongSwan dependency to 6.0.6, extends schema validation and completion lists for ESP PFS and IKE proposals, and updates cipher template lookups. ChangesML-KEM Post-Quantum IPsec Group Support
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
❌ Typos detected in PR (8 found)
|
There was a problem hiding this comment.
🧹 Nitpick comments (1)
python/vyos/template.py (1)
509-512: ⚡ Quick winAdd unit coverage for new ML-KEM DH-group mappings.
get_esp_ike_cipher()now mapsdh-group33/34/35, but existing template tests only assert legacy groups. Add assertions formlkem512/mlkem768/mlkem1024render output to lock the cross-file contract.Proposed test addition
--- a/src/tests/test_template.py +++ b/src/tests/test_template.py @@ def test_cipher_to_string(self): ... + + def test_cipher_to_string_mlkem_groups(self): + data = { + 'proposal': { + '10': {'encryption': 'aes256gcm128', 'hash': 'sha256'} + } + } + + data['pfs'] = 'dh-group33' + self.assertIn('mlkem512', ','.join(vyos.template.get_esp_ike_cipher(data))) + + data['pfs'] = 'dh-group34' + self.assertIn('mlkem768', ','.join(vyos.template.get_esp_ike_cipher(data))) + + data['pfs'] = 'dh-group35' + self.assertIn('mlkem1024', ','.join(vyos.template.get_esp_ike_cipher(data)))🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@python/vyos/template.py` around lines 509 - 512, The template added mappings for 'dh-group33/34/35' -> 'mlkem512/mlkem768/mlkem1024' in the mapping used by get_esp_ike_cipher, but the template unit tests still only assert legacy DH groups; update the template tests that validate ESP/IKE cipher rendering to include assertions that inputs using dh-group33, dh-group34, and dh-group35 produce mlkem512, mlkem768, and mlkem1024 in the rendered output respectively so the cross-file contract is locked. Locate the mapping in template.py (the dh-group33/34/35 entries) and the test(s) that call get_esp_ike_cipher or render the template, and add three assertions covering those new mappings.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@python/vyos/template.py`:
- Around line 509-512: The template added mappings for 'dh-group33/34/35' ->
'mlkem512/mlkem768/mlkem1024' in the mapping used by get_esp_ike_cipher, but the
template unit tests still only assert legacy DH groups; update the template
tests that validate ESP/IKE cipher rendering to include assertions that inputs
using dh-group33, dh-group34, and dh-group35 produce mlkem512, mlkem768, and
mlkem1024 in the rendered output respectively so the cross-file contract is
locked. Locate the mapping in template.py (the dh-group33/34/35 entries) and the
test(s) that call get_esp_ike_cipher or render the template, and add three
assertions covering those new mappings.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Run ID: b1ba7dd3-8319-430a-876b-3352af7196b2
📒 Files selected for processing (3)
debian/controlinterface-definitions/vpn_ipsec.xml.inpython/vyos/template.py
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
ansible/ansible(manual)
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: build_iso
- GitHub Check: codeql-analysis-call / Analyze (python)
- GitHub Check: Mergify Merge Protections
- GitHub Check: Summary
🧰 Additional context used
📓 Path-based instructions (1)
**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
**/*.py: Python code must target Python 3.11 or higher
Prefer storing Jinja2 templates as discrete files underdata/templates/rather than inline Python strings
Use ruff (version 0.6.4), darker, pylint W0611, and Jinja2 lint for linting; configuration viaruff.tomlandnose2.cfgat repository root
Files:
python/vyos/template.py
🔍 Remote MCP
Excellent. I have gathered sufficient context about strongSwan 6.0.x and ML-KEM support. Let me search for information about the specific Diffie-Hellman group numbering (dh-group33, dh-group34, dh-group35) to understand the mapping to ML-KEM variants.The search didn't directly return the IANA registry mapping. Let me search more specifically for ML-KEM group numbers.I have gathered comprehensive information about strongSwan 6.0.x, ML-KEM support, and related technical context. While I found information about ML-KEM in general and its IANA codepoints for TLS (0x0200, 0x0201, 0x0202), the search results don't provide the specific IANA registry mapping for dh-group33/34/35 in IKEv2. However, I have sufficient context to provide a meaningful summary. Let me compile the review context now.
Additional Relevant Context for PR #5267 Review
StrongSwan 6.0.x ML-KEM Support
StrongSwan 6.0.0 brings support for multiple classic and post-quantum key exchanges and supports ML-KEM. ML-KEM (FIPS 203) support has been added via Botan 3.6.0+ (botan plugin), wolfSSL 5.7.4+ (wolfssl plugin), AWS-LC 1.37.0+ (openssl plugin), and the new ml plugin. Additionally, ML-KEM is now supported via OpenSSL 3.5+ by the openssl plugin in StrongSwan 6.0.2.
Post-Quantum Key Encapsulation (ML-KEM)
The Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM, FIPS 203) is a mechanism to establish a shared secret that is believed to be secure even against adversaries with a quantum computer, with keywords for ML-KEM-512, ML-KEM-768 (3), and ML-KEM-1024 (5) being mlkem512, mlkem768 and mlkem1024, respectively. NIST recommends using ML-KEM-768 as the default parameter set, as it "provides a large security margin at a reasonable performance cost."
RFC 9370 - Multiple Key Exchanges in IKEv2
Support for multiple IKEv2 key exchanges (RFC 9370) allows up to seven additional key exchanges (classic or post-quantum) to establish key material when negotiating IKE and/or Child SAs. In proposals, additional key exchange methods are configured with a keX_ prefix, where X is a number between 1 and 7.
Performance Considerations
ML-KEM outperforms classic DH groups, with ML-KEM-768 faster than the fastest ECP group (DH group 19/ECP 256), and ML-DSA-65 certificate authentication having similar performance with RSA2048 certificates.
Security Against Quantum Threats
A Cryptographically Relevant Quantum Computer would pose a threat to current public key establishment algorithms, allowing "harvest-now-decrypt-later" attacks where encrypted communications using (EC)DH could be decrypted in the future after a CRQC became available. ML-KEM can be used as a quantum-resistant key exchange in IKEv2, and is believed to be infeasible to break, even by adversaries with a CRQC.
Implementation Requirements
Support for PQC algorithms in strongSwan is available only from version 6.0.0 onwards, which aligns with the PR's requirement to upgrade to strongSwan 6.0.6.
🔇 Additional comments (2)
debian/control (1)
311-318: LGTM!interface-definitions/vpn_ipsec.xml.in (1)
182-182: LGTM!Also applies to: 276-287, 293-293, 476-476, 566-577, 579-579
|
CI integration ❌ failed! Details
|
Change summary
Types of changes
Related Task(s)
Related PR(s)
How to test / Smoketest result
Setup IPSEC, but use
Then check
Checklist: